An increasing number of companies and other enterprises are reducing their costs by migrating portions of their information technology (IT) infrastructure to cloud service providers. For example, virtual data centers and other types of systems comprising cloud infrastructure are coming into widespread use. Typical cloud service offerings include, for example, Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and Software-as-a-Service (SaaS). In cloud-based information processing systems, enterprises in effect become tenants of the cloud service providers.
A given enterprise tenancy maintained in cloud infrastructure by a cloud service provider will typically comprise a large number of protected resources, such as applications, computational resources and storage resources. It is important that access to such resources be controlled in a secure manner. In one conventional arrangement, a user can establish a session with the cloud service provider in order to access one or more of the protected resources of the enterprise tenancy. This may involve the user obtaining an attestation or other security token from an identity provider and presenting it to the cloud service provider in order to obtain access to the protected resources.
However, arrangements of this type often require that the access control entity either maintain a live connection back to the identity provider or provide local persistent storage for user identifiers and other associated security attributes.
The maintenance of a live connection back to the identity provider is problematic in that it complicates session management and introduces additional opportunities for attackers. It may also present a conflict with well-established network perimeter controls.
The use of local persistent storage to hold user attributes is also problematic in that the private user attribute information that is held persistently by the cloud service provider is directly vulnerable in the event that the security of the cloud infrastructure is breached.
Also, persistent storage of such information will often require the cloud service provider to maintain one or more access control list (ACL) databases in order to support aliasing between a user identifier or other user attribute associated with the security token obtained from the identity provider and a locally defined identifier for use within the cloud infrastructure. Provisioning and maintaining such ACL databases can be unduly costly and inefficient for the cloud service provider.
Conventional single sign-on (SSO) approaches are also problematic in that such approaches generally assume that the cloud service provider has an on-going ability to validate a security token with the original external source of that token. As indicated previously, it is often not possible in cloud environments to maintain a live connection back to an external identity provider in order to support such functionality.